<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Checklist: Design</title>
<meta name="uma.type" content="Checklist">
<meta name="uma.name" content="design">
<meta name="uma.presentationName" content="Design">
<meta name="element_type" content="Checklist">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', true, false, false);
					
					//override the subsection text
					contentPage.subSection.expandAllText = 'Expand All Check Items';
					contentPage.subSection.collapseAllText = 'Collapse All Check Items';					
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_0XSzsMlgEdmt3adZL5Dmdw"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Checklist: Design</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/checklist.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top"></td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Analyze the Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/workproducts/design_D677D182.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html" guid="_bFjlAPTYEduDKIuqTXQ8SA">Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Evolve the Design</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/refactoring_F3D63EBD.html" guid="_YNx2sJ05EdyQ3oTO93enUw">Refactoring</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Check Items</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="sectionTableCell">
<div class="stepHeading">The design is understandable</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Is the design organized in a way that team members can easily find the information that they're looking for?
    </li>
    <li>
        Is the design as simple as it can be, while still fulfilling the objectives of the design and giving sufficient
        direction to implementers?
    </li>
    <li>
        Is the design neither too simple nor too advanced? The design sophistication should be appropriate to the
        experience level of other team members and technical stakeholders. This applies to both the concept and the
        representation of the design.
    </li>
    <li>
        Does the design express what the designer intends to express?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design is consistent</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Does the design follow any design standards?
    </li>
    <li>
        Does&nbsp;the design&nbsp;apply other idioms consistently?
    </li>
    <li>
        Are the names of the design elements consistent and easy to interpret?
    </li>
    <li>
        Does any part of the design contradict another part of it in such a way that puts the project at risk?
    </li>
    <li>
        If the design is rendered visually, is the notation used to&nbsp;describe the design used consistently so that it
        can be understood and is not ambiguous?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design is maintainable</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Is the design structured well enough to be maintained?
    </li>
    <li>
        Is the design set up to appropriately accommodate expected changes? The design should not be overdone to handle
        <em>any</em> possible change, just reasonably expected changes.
    </li>
    <li>
        Have redundant areas of the design been removed so that the implementation does not contain redundant code?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design is traceable</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Is it clear how the design elements relate to the requirements? This does not need to involve a heavyweight
        traceability strategy, but is there some way to figure out what part of the design supports a particular
        requirement?
    </li>
    <li>
        It what portions of the implementation support each design element clear?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design reflects the architectural objectives of the system</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Does the design conform to the architecture as specified?
    </li>
    <li>
        Does it apply the architectural patterns appropriately?
    </li>
    <li>
        Are Architectural Mechanisms used appropriately? Are they applied in all applicable circumstances?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design elements are modular</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Do the design elements have high internal cohesion? Does the degree of interaction within the unit demonstrate that
        all of the internal parts belong together?
    </li>
    <li>
        Do the design elements have low coupling? Is there minimal interdependence between design elements? When design
        elements depend upon one another, is this done as simply as possible and in such a way that the client element will
        not be affected by changes to the internal parts of the supplier element?
    </li>
    <li>
        Are the design elements defined with&nbsp;abstract interfaces in ways that changes can be made to the internal
        implementation without affecting client design elements?
    </li>
    <li>
        Does each design element represent a clearly defined abstraction?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The system can be implemented from the information in the design</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Has sufficient detail been included to direct the implementation?
    </li>
    <li>
        Does the design constrain the implementation only as much as necessary? Does the design allow freedom for the
        implementer to implement it appropriately?
    </li>
    <li>
        Is the design feasible? Is it a design that can be reasonably implemented by the team by using the technologies
        selected within the timeframe of the project?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design provide enough information for developer testing</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Does the design provide enough information for developer test design? Are the expected behavior and constraints on
        the methods clear?
    </li>
    <li>
        Are the collaborations between design elements clear enough to create integration tests?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">The design describe the system at the appropriate level of abstraction</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td>Does the design describe the system at the appropriate level of abstraction given the objectives? This usually means that
the system is described at several different levels of abstraction and from different perspectives.</td>
</tr>
</table>
</div>
<div class="stepHeading">The design supports a coarse-grained perspective of the system</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><ul>
    <li>
        Can the design be understood as a set of higher-order subsystems?
    </li>
    <li>
        Are the subsystem dependencies documented?
    </li>
    <li>
        Are interfaces clearly defined for each subsystem? Is each subsystem designed so that its services can be accessed
        through the interface without a need to access internal parts?
    </li>
    <li>
        Is each subsystem designed so that someone can work within one part without having to understand the internal parts
        of the other elements?
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading">Packages and Organization</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    Is the package partitioning logical and consistent? Does it make sense to team members and stakeholders?
</p>
<p>
    Do package names accurately describe the contents of the package and the role they play in the architecture? Do they
    follow naming conventions?
</p>
<p>
    Do public packages and interfaces provide a logically cohesive set of services?
</p>
<p>
    Are all the contents of a package listed? Are the classes within a package cohesive?
</p>
<p>
    Do package dependencies correspond to the dependencies of the contained classes?
</p>
<p>
    Are there packages or classes within a package that can be separated into and independent or sub-package?<br />
</p></td>
</tr>
</table>
</div>
<div class="stepHeading">Views</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    Does each diagram help the designer reason about the design, or communicate key design decisions to the team?
</p>
<p>
    Are the relationships between diagrams clear when several diagrams are used to describe behavior?
</p>
<p>
    Is it easy to navigate between related diagrams?
</p>
<p>
    Does each diagram focus on a relevant perspective? For instance, does a set of diagrams show a single class and its
    direct relationships, rather than using&nbsp;one or two diagrams to show all classes?
</p>
<p>
    Is each diagram complete and minimal? Does it show everything relevant to that view and nothing more?
</p>
<p>
    Are the diagrams tidy and easy to interpret, with a minimum of clutter?
</p></td>
</tr>
</table>
</div>
<div class="stepHeading">UML</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    Does the visual model conform to UML standards so all stakeholders can understand the model over time? See the&nbsp;<a href="http://www.uml.org/" target="_blank">OMG UML Resource Page</a>&nbsp;for more information.
</p>
<p>
    Does the visual model conform to project or organization specific modeling standards?
</p>Is the visual model internally consistent? For instance, if an object diagram shows a relationship between objects,
does a corresponding relationship exist between the appropriate classes?<br />
<p>
    Does the name of each class clearly reflect the role it plays?
</p>
<p>
    Does each class offer the required behavior?
</p>
<p>
    Is there at least one&nbsp;realization association defined for each interface? The realization may represent a 3rd
    party implementation of the subsystem.
</p>
<p>
    Are&nbsp;there dependency associations from each subsystem to the interfaces it uses?
</p>
<p>
    Is each operation in a subsystem interface described in a sequence diagram? Or at least mapped directly to an operation
    in a class?
</p>
<p>
    Does each class represent a single well defined abstraction?
</p>
<p>
    Are generalization relationships used only to inherit definitions, not behavior (implementation)? In other words, is
    behavior shared through the use of association, aggregation and containment relationships instead of generalization?
</p>
<p>
    Are parent classes in generalization relationships abstract? Are the "leaf" classes in a generalization hierarchy the
    only concrete classes?
</p>
<p>
    Are stereotypes used consistently and meaningfully?
</p>
<p>
    Do&nbsp;statecharts exist for classes with complex or restrictive state changes?
</p>
<p>
    Do relationships have descriptive role or association names (one or the other but not both), and&nbsp;correct
    multiplicities?
</p>
<p>
    Are relationships between classes unidirectional whenever possible?<br />
     &nbsp;
</p></td>
</tr>
</table>
</div>
<div class="stepHeading">Non-UML Visual Modeling</div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><p>
    Are the semantics of the visual modeling language clearly defined, documented, and accessible to team members? The
    semantics should be meaninful to the users of the model.
</p>
<p>
    Can the semantics of the modeling language be understood over time? Is the language documented well enough so that team
    members can understand the model long after design decisions have taken place?
</p>
<p>
    Are team members and stakeholders trained in the modeling language being used?
</p>
<p>
    Does the visual model conform to the semantics of the visual modeling language? In other words, are the meanings
    of&nbsp;the symbols in the diagrams&nbsp;consistent across the model and diagrams?&nbsp;
</p></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
